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Claim Rejections - 35 USC §112 

1 . The following is a quotation of the second paragraph of 35 U.S.C. 1 1 2: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

2. Claims 22 and 26 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. A "single means" claim (as recited in claim 22) is not 
allowed under section 112. Independent claims 22 and 26 recite conditional phrases 
such as "if said node" or "unless said node", which are indefinite. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1, 22 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over U.S. Patent Pub. 2004/0266394 to Mizell et al. (hereinafter "Mizell") in view of U.S. 
Patent Pub. 2006/005071 1 to Lialiamou et al. (hereinafter "Lialiamou"). 

Regarding claim 1, Mizell teaches an arrangement, for allowing compensation of 
lost, discarded or unsent traffic on the downlink in a communication system supporting 
communication of packet data and classification of mobile traffic allowing application of 
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different charging scliennes for different types of traffic (see Fig. 2), comprising a packet 
data node (GGSN 120) liandling classification of traffic into different types, including 
service class, and for applying an appropriate charging scheme depending on type (see 
step 272 in Fig.7 "In the GGSN, generate a corresponding charging record relating a 
charge rate to a quantity of data packets transmitted at the charge rate" as described in 
section [0044], GGSN inspects packets to determine (recited "handle") content type, 
see section [0031]), that said node provides and sends information relating to type, 
including service class, to subsequent nodes on the downlink to a mobile station (GGSN 
transmits content aware billing rate information which is "related to class of service" to 
SGSN, additionally, any packet received at GGSN (from IP network 128) which includes 
"class of service" information in it's header, when forwarded by GGSN to SGSN, the 
GGSN will "handle and provide information relating to type, including service class, to 
subsequent nodes"), wherein a subsequent node detecting a packet loss, notes said 
loss and enables use of the information of said loss together with type information to 
enable for correction of charging due to traffic loss (see steps 288 and 292 in Fig. 7, 
where the SGSN generates a report relating to charge rate and number of packets 
transmitted and calling gateway function (CGF) determines charge based on reports 
from GGSN and SGSN) . 

As described above, although Mizell is "content aware", teaches supporting 
different levels of QoS (see section [0009]), provides additional billing rate information in 
the header of content based on the type content and may also inherently "handle and 
provide information relating to service class" (by forwarding service class information 



Application/Control Number: 10/595,057 Page 4 

Art Unit: 2617 

already included in packet headers), Mizell does not explicitly teach that the GGSN 
"provides and sends information relating to service class", as recited. 

In an analogous art, Lialiamou teaches a system which provides different 
charging policies based on a determined type of flow and/or QoS (see Abstract and 
section [0044]). Fig. 3 of Lialiamou shows a network element (which is a GGSN) which 
determines a type of flow and applies the appropriate charging policy. Lialiamou 
teaches in sections [0064] to [0067] that the type of flow is determined by "flow 
parameters" such as "type of service" and "traffic class" information included (and read 
by the GGSN) in the packets. As described in sections [0056] to [0057] for example, 
the GGSN outputs a call detail record (CDR) for billing purposes which includes 
"information on flow definitions" (recited "class of service", as a flow is defined by QoS, 
"type of service" or "traffic class"), amount of data included in the flow, and the charging 
information of the flow. 

Therefore, as both Mizell and Lialiamou teach billing based on content and 
volume of content, it would have been obvious to one of ordinary skill in the art to 
modify Mizell to "provide class of service information" to a subsequent node, in order to 
allow the subsequent node to properly identify a class of service (and associated lost 
packets) and produce accurate billing records for the identified class of service. 

Regarding independent claims 22 and 26, which recite features similar to claim 1, 
see the rejection of claim 1 . Regarding the feature (in claims 22 and 26) reciting that 
the subsequent node (SGSN) sends reports relating to discarded/lost traffic packets. 



Application/Control Number: 10/595,057 Page 5 

Art Unit: 2617 

with type information, to said packet data node (GGSN), " unless or if the node (SGSN) 
does not support content based charging", as the SGSN (in Mizell) generates a billing 
record (which is transmitted to the CGF), the SGSN may be interpreted to "support 
content based charging", therefore the SGSN does not have to perform this recited 
feature (of transmitting the report back to the GGSN). 

5. Claims 2-8, 10-11, 13-16, and 21-31 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Mizell and Lialiamou as applied to claim 1 above, and further in 
view of U.S. Patent 7,177,277 to Koponen et al. (hereinafter "Koponen"). 

Regarding independent claims 22 and 26, which recite features similar to claim 1 , 
see the rejection of claim 1 . Regarding the feature (in claims 22 and 26) reciting that 
the subsequent node (SGSN) sends reports relating to discarded/lost traffic packets, 
with type information, to a preceding packet data node (GGSN), "if the node (SGSN) 
does not support content based charging", Mizell and Lialiamou do not explicitly teach 
this feature. 

In an analogous art, Koponen teaches classifying packets based on different 
classes (or priorities) and transmitting packet acknowledgements from an SGSN to a 
GGSN. Koponen also teaches that a "GGSN is responsible for collecting and billing 
data" (see column 3). Column 10, lines 40-45 of Koponen recites "It Is also possible to 
define a message interface between the SGSN and the GGSN so that the SGSN would 
inform the GGSN if it discards a packet. Then the GGSN could avoid erroneous 
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charging". Therefore, as Koponen is also related to providing accurate billing based on 
successfully delivered packets, it would have been obvious to modify Mizell to transmit 
a charging report from the SGSN to the GGSN, when billing is performed in the GGSN, 
as is conventional. 

Regarding claim 2, which recites "wherein radio nodes provide 
correction/compensation for lost traffic at predetermined intervals loss reports are 
provided to a preceding packet data node, said loss reports including at least said type 
information for said discarded/lost data traffic and said packet data nodes includes said 
type Information In a new field in a Call Detail Record or similar", see the CDR reports 
sent in Mizell and Lialiamou, which are CDRs as recited. Regarding the feature that 
"radio nodes" provide correction for lost traffic, see for example, column 6, lines 42-44 
and column 7, lines 5-7, which teach the "radio part 30" (recited radio nodes) 
transmitting packet retransmission requests to the SGSN, the GGSN and acceleration 
server 45. Therefore, as the communication network shown in Fig. 1 of Mizell employs 
mobile stations 104, base station controllers 108 and RNS 136 (which are radio nodes), 
and as packet acknowledgement and retransmission requests (as taught by Koponen) 
are also conventionally performed between these other downstream nodes (mobile 
station, base station and RNC), it would have been obvious to modify the packet 
retransmission requests (recited "compensation for lost traffic at predetermined intervals 
loss reports") to be performed by these downstream (recited "radio nodes"), in order to 
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ensure that packets are also successfully delivered downstream of the SGSN, as is 
conventional. 

Regarding claim 3, which recites "wherein charging correction/compensation for 
lost traffic is performed in real time and loss reports are provided from radio nodes to a 
preceding packet data node at occurrence of the loss, and in that a loss report including 
type information is provided to the packet data node supporting flexible charging 
together with subscriber information and access point identification in a new message, 
e. g. a new GTP-message", see the rejection of claim 2 above. Regarding the feature 
of "a new GTP message", as Mizell repeatedly teaches using GTP protocols, it would 
have been obvious to one of ordinary skill in the art to put subscriber information (which 
would be included in the generated CDR) in a new GTP message, as is conventional 
when using GPRS networks. Regarding the feature that the reports are in real time, the 
reports of Mizell and Lialaimou are performed in real time and the retransmission 
requests of Koponen are in real time, as recited. 

Regarding claim 4, which recites "wherein the packet data node comprises a 
packet data node with a gateway functionality", the GGSNs of Mizell and Lialiamou 
have gateway functionality, as recited. 

Regarding claim 5, which recites "wherein that the packet data node comprises a 
serving packet data node", see column 10, lines 32-34 of Koponen, which teach that a 
"SGSN, GGSN and accelerating server could be incorporated into s single device". 
Therefore it would have been obvious to modify the packet data node of Mizell to 
include a "serving packet data node" (or SGSN), as recited. 
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Regarding claim 6, wliicli recites "wherein tlie pacl<et data node comprises a 
packet data serving functionality and a gateway functionality", as described above in the 
rejection of claim 5, column 10, lines 32-34 of Koponen render obvious a packet data 
node with both SGSN and GGSN functionality, as recited. 

Regarding claim 7, which recites "wherein said packet data node handling 
classification and labeling provides traffic packets with service class information and 
rating information", the GGSN of Mizell as modified by Lialiamou, provides "service 
class information and billing (recited "rating") information", as recited. 

Regarding claim 8, which recites "wherein said packet data node handling 
classification and labeling provides traffic packets service class information and a time 
stamp", although Mizell and Lialaimou do not explicitly teach a "time stamp", this 
information would be obvious to include in a CDR, as is conventional, and in view of 
Lialaimou's teaching of time-based billing, which would motive one of ordinary skill to 
include a time stamp. 

Regarding claim 10, which recites "wherein the packet data node is an access 
node in a GSM/GPRS system in communication with BSCs", see Fig. 1 of Mizell which 
shows the data packet nodes (GGSN 120 and SGSN 116) communicating with BSC 
108, as recited. 

Regarding claim 1 1 , which recites "wherein the packet data is an access node 
supporting a UMTS/GPRS system and supports communication with RNCs", see Fig. 1 
of Mizell which shows the data packet nodes (GGSN 120 and SGSN 140) 
communicating with RNC 136, as recited. 
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Regarding claim 13, wliicli recites "wherein loss reports relating to discarded 
traffic are sent periodically and at given times", the reports of Mizell and Lialaimou and 
the retransmission requests of Koponen are all sent periodically, as recited. 

Regarding claim 14, which recites "wherein loss reports relating to discarded 
traffic are sent based on the volume of given types of the discarded traffic or service 
classes", a request fro retransmission report in Koponen is based on "volume" (of at 
least one) discarded packet of traffic, as recited. 

Regarding claim 15, which recites "wherein loss reports relating to discarded 
traffic are provided/sent in real time, substantially instantly at the occurrence of a loss 
directly or indirectly to the node handling flexible charging", the reports of Mizell and 
Lialaimou and the retransmission requests of Koponen are all sent in real time, as 
recited. 

Regarding claim 16, which recites "wherein the classification and charging 
scheme application handling is performed by a gateway packet data node and in that it 
supports a content based charging functionality", the GGSN of Mizell (as modified 
above) performs these features, as recited. 

Regarding claim 21 , which recites "wherein the subsequent nodes register at 
least type and amount of information about discarded packets", the SGSN of Mizell 
"registers at least type and amount of information about discarded packets", as recited. 

Regarding claim 23, which recites "further comprising a serving packet data 
support node (SGSN), a gateway packet data support node (GGSN) or a combined 
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gateway and serving packet data support node (CGSN)", see GGSNs of Mizell and 
Lialiamou, as recited. 

Regarding claim 24, which recites "further comprises means for forwarding 
service class information (QoS), rating information or time stamp information for sent 
packets and optionally for chain information (chain id) to subsequent nodes", as 
described above, Mizell sends billing or "rating" information and Mizell as modified by 
Lialiamou, sends service class information, as recited. 

Regarding claim 25, which recites "further comprises means for supporting real 
time compensation/correction for lost packets, wherein loss reports are provided in real 
time", the retransmission requests in Koponen "support real time compensation", and 
the reports of Mizell are provided in real time, as recited. 

Regarding claim 27, which recites "wherein the step of sending information 
comprises sending service class, rating information or providing a time stamp for a 
packet and, optionally, information for identifying the chain an IP packet belongs to", as 
described above, Mizell sends billing or "rating" information and Mizell as modified by 
Lialiamou, sends service class information, as recited. 

Regarding claim 28, which recites "wherein the reporting step comprises: 
sending a report including subscriber id (IMSI), access point id (NSAPI) from a node, 
upon detecting that a packet is discarded, to allow for real time 
compensation/correction, wherein such node further registers discarded packet type 
and amount of discarded packets", as the report sent from SGSN of Mizell is a call 
detail record and he report sent in Lialiamou is a call detail record (CDR), although an 
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IMSi and NSAPI are not explicitly mentioned, these would be obvious (if not inherently 
necessary) to include in a CDR, in order to bill the identified subscriber, as is 
conventional. Regarding the "real time compensation/correction of lost packets", the 
retransmission requests of Koponen allow for real time compensation, as recited. 

Regarding claim 29, which recites "wherein the reporting step comprises: 
introducing the reporting information in a packet sent over the relevant protocol between 
nodes up to the node handling classification/content based charging", the reporting in 
Mizell and Lialiamou is sent "over the relevant protocol between nodes up to the node 
handling classification/content based charging", as recited. 

Regarding claim 30, which recites "wherein the node handling 
classification/charging comprises one of a gateway packet data node (GGSN), a 
serving packet data node (SGSN) or a combined gateway and serving packet data 
node (CGSN)", the "node handling classification/charging" is the GGSN of Mizell. 

Regarding claim 31, which recites "wherein reporting is performed based on 
volume, with given time intervals or at given points in time", see for example, sections 
[0044] and [0061] of Lialiamou, which teaches volume metering and counters, as 
recited. 

6. Claims 12 and 17-18 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Mizell and Lialiamou as applied to claim 1 above, and further in view of U.S. Patent 
7,072,358 to Suvanen (hereinafter "Suvanen"). 
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Regarding claim 12, which recites "wherein the packet data node is a dual 
access node supporting communication with BSC'S and RNC's", Fig. 1 of Mizell teaches 
data packet nodes communicating with BSCs and RNCs separately. 

In an analogous art, Suvanen shows in Fig. 3 an access node which is a dual 
access node capable of communicating with both BScs and RNCs. Therefore, given 
the teachings of combining devices (and functions) of multiple devices into a single 
device, it would have been obvious to modify the packet data node of Mizell to be a 
"dual access node", in order to be compatible with both UMTS and GSM networks, as is 
conventional. 

Regarding claim 17, which recites "wherein information relating to type is 
provided to a packet data node with a serving functionality, and said node forwards 
such information to subsequent nodes, and if a different protocol is used than the 
protocol used between the serving node and the gateway packet data node, a 
conversion is performed such that the information can be sent over said different 
protocol", see for example, claim 2 of Suvanen, which teaches converting data to either 
UMTS or GSM protocols. Therefore, it would have been obvious to one of ordinary skill 
in the art to "convert protocols" in Mizell "if a different protocol is used than the protocol 
used between the serving node and the gateway packet data node", as recited, in order 
to be compatible with different types of networks, as is conventional. 

Regarding claim 18, which recites "wherein the serving packet data node is a 
SGSN, the gateway packet data node is a GGSN and in that the information relating to 
at least type is added to the GTP header of the downlink payload to SGSN, if relevant to 
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RNC's, whereas if it is to be forwarded to BSC'S, the information is included in the 
BSSGP header", Mizell as modified above, includes type information in a header (when 
relevant to RNCs), as recited. Regarding the feature that the "information is included in 
the BSSGP header" (when relevant to BSCs), given the teachings of the references, it 

would have been obvious to one of ordinary skill in the art to "information is included in 
the BSSGP header", in order to be compatible with different types of networks and 
devices, as is conventional. 

7. Claims 9 and 19-20 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Mizell, Lialiamou and Koponen as applied to claim 3 above, and further in view of 
the specifications documents cited in the instant specification. 

Regarding claim 9, which recites "wherein the traffic packets are provided with 
chain identification information", as chain identification information is conventional data 
(taught in the standards documents cited in the instant application on pages 5, 6 and 8) 
it would have been obvious to one of ordinary skill in the art to modify Mizell to include 
this information, in order to correctly track packet losses, as is conventional. 

Regarding claim 19, which recites "wherein an RNC having discarded traffic, a 
loss report comprising a RANAP Data Volume Report is sent at occurrence of the loss 
of data to the preceding packet data node uplinks and unless such preceding node 
handles flexible charging, it sends the new loss report message with IMSI, NASAPI to 
the node handling such functionality", although the packet retransmissions of Koponen 
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(which come from radio nodes such as an RNC), may include indications of volume of 
traffic, these reports are not explicitly "data volume reports". As cited on page 8 of the 
instant specification the 3GPP TS 25.413 specification teaches "data volume reports". 
Therefore, in order to communicate with specific devices/networks, it would have been 
obvious to modify Mizell to use data volume reports, as is conventional. 

Regarding claim 20, which recites "wherein for a BSC having discarded traffic, a 
loss report including at least service class information, rating information or a time 
stamp, is sent to the preceding packet data node uplinks at occurrence of the loss for 
charging correction/compensation, wherein said packet data node, unless the packet 
data node handles the flexible charging functionality, provides the new loss report 
message with IMS!, NSAPI to the node handling such functionality", Mizell as modified 
above sends service class information and rating information to a preceding node, as 
recited. Additionally, as cited on page 6 of the instant specification the 3GPP TS 48.018 
specification teaches using IMS! and NSAPI identifiers. Therefore, in order to 
communicate with specific devices/networks, it would have been obvious to modify 
Mizell to use data volume reports, as is conventional. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to STEVEN KELLEY whose telephone number is (571 ) 
272-5652. The examiner can normally be reached on Monday-Friday, 9AM to 5PM. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Lester Kincaid can be reached on (571) 272-7922. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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/LESTER KINCAID/ 

Supervisory Patent Examiner, Art Unit 2617 



